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METHOD OF BRIDGING BETWEEN .NET AMD JAVA 

FIELD 

5 The invention is related to methods of bridging 

between different computer languages and platforms, 
specifically between Java and Microsoft's .Net framework. 

BACKGROUND 

10 

Web Services are part of the development in 
Microsoft's .Net framework for client-server 
comnruni cat ions . The .Net specification provides for two 
methods of accessing Web Services, SOAP (Simple Object 
15 Access Protocol) and .Net Remoting. 

A Web Service is a unit of application logic providing 
data and services to other applications. Applications 
access Web Services via ubiquitous Web protocols and data 
20 formats such as HTTP, XML, and SOAP, The .Net platform 
from Microsoft represents one system of providing web 
Services . 

SOAP is an RPC mechanism that uses XML, usually over 
25 HTTP, to allow a client to access a server. SOAP is 

beneficial as it is an open- standard XML format allowing 
communication between different platforms. There exist 
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several implementations of SOAP technologies for these . 
platforms, as well as Java. 

However, SOAP has limitations. The most significant 
5 is that the XML format is often not as fast or efficient as 
a high-speed binary format. 

Also, SOAP lacks support for certain features. 
Notably, SOAP does not support activation of lifetime 
10 control of remote objects by the client (like DCOM for 

Windows) . There is also no support for passing objects by 
reference and no support for callbacks or events. 

SOAP also lacks some of the features provided by . Net . 
15 One is the lack of support for additional context 

information which is specific to .Net. It is intended that 
such information will be used in the future to enable 
features such as distributed transactions and additional 
security levels. 

20 

.Net Remoting is an alternative to SOAP, .Net 
Remoting is a distributed object protocol that uses binary 
or SOAP-based format over TCP or HTTP to allow a client to 
access a server. .Net Remoting addresses the limitations 
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of SOAP by supporting additional features, but at the same 
time introduces limitations of its own. 

The primary limitation of .Net Remoting is that it is 
5 specific to the .Net Framework and will only work with 

other .Net Frameworks. This presents a particular problem 
for developers and organizations that use Java and wish to 
combine the .Net Framework with Java. 

10 It is an object of this invention to provide a method 

of bridging between Java and the .Net Framework. This 

| method of bridging allows Java clients to use the .Net 

I Remoting protocol to interact with a Web Service running in 

I the .Net Framework. This method also allows .Net Framework 

h 15 clients to communicate with Java-based applications using 

I the .Net Remoting protocol. 

SUMMARY 

20 The invention is a method for allowing Java objects to 

communicate with .Net Remoting objects, with a first step 
of receiving metadata information from a .Net Remoting 
server on a Java client. Then/ Java proxies are generated 
from said metadata information, using a Java development 

25 tool, with the Java proxies generated by a one-to-one 
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mapping of .Net classes to Java classes. Finally, the Java 
proxies are implemented, on the Java client, with the method 
provided solely in Java. Therefore the Java client does 
not require any .Net .components. 

5 

Preferably, the method also has a Java runtime tool 
for handling the Java proxies. This Java runtime tool may 
be capable of independent operation. 

10 The invention further includes a method for allowing 

.Net Remoting objects to communicate with Java objects, 
with a first step of receiving metadata information from a 
Java server on a .Net Remoting client. Then, .Net proxies 
are generated from said metadata information, using a Java 

15 development tool, with the .Net proxies generated by a one- 
to-one mapping of Java classes to .Net classes. Finally, 
the .Net proxies are implemented on the .Net client, with 
the method provided solely in CLR metadata. Therefore the 
.Net client does not require any Java components. 



20 



25 



The invention also includes a computer program capable 
of implementing the above methods . 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention itself both as to organization and 
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method of operation, as well as additional objects and 
advantages thereof, will become readily apparent from the 
following detailed description when read in connection with 
the accompanying drawings: 

5 

Figure 1 is a diagram showing the process of 
generating Java proxies from .NET components; 

Figure 2 is a diagram showing the process of 
10 generating .NET proxies from Java components; 

Figure 3 is a diagram showing the process of Java 
client to .Net component communication using proxies; 

15 Figure 4 is a diagram showing the process of .Net 

client to Java component communication using proxies. 

DETAILED DESCRIPTION 
20 The invention is designed to allow Java applications 

to talk to .Net Remoting objects without any .Net 
components running on the Java platform and will be 
referred to as Ja.Net (Java-. Net communication). Ja.Net is 
a 100% Java-based program designed as a solution to the 
25 Java- to-. Net communication problem, unlike other possible 

5 
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solutions that require the .Net Framework and the Java 
virtual Machine to be running on the same machine. 

ja.Net operates in two modes. A development mode 
5 generates the necessary proxies to enable communication 
with a Java or .Net component. A runtime mode allows a 
user application to use the generated proxies to 
communicated with a Java or .Net component. 

10 .Net Remoting 

.Net Remoting is an protocol that facilitates 
distributed object level computing, Common Language 
Runtime (CLR) , also referred to as .Net Runtime, supports 

15 many different languages, including C#, Visual Basic. Net, 
and C++. Ja.Net allows Java components to appear as CLR 
components, and CLR components to appear as Java 
components , 

20 .Net Remoting permits the use of a number of different 

transport protocols and data formats. Currently, HTTP and 
TCP/IP transport protocols are supported along with SOAP 
and binary data formatting. 
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Java to .Net development 

The first type of implementation of Ja.Net is one that 
allows Java objects to talk to .Net Remoting objects. In 
5 other words, a Java client is enabled to understand .Net 
Remoting protocols. Any supported transport protocol and 
data format supported by .Net Remoting can be used. 

The development steps for Java-to-.Net communication 
10 are shown in the flowchart of Figure 1. The first step 10 
is for the user to specify a name and location for the .Net 
H Remoting server using a Genjava tool to interact with 

if GenService, a continuous running service on the .Net 

m Framework. 



15 



20 



The next step 12 is to read the metadata which is 
related to the server application using GenService. The 
metadata is then sent (step 14) to the Java client as an 
XML file. 



After receiving the metadata XML file, the Java client 
must generate (step 16) the necessary Java proxies to 
parallel the classes and interfaces listed in the metadata. 
The generated classes have all the methods and properties 
25 of the .Net classes. A mapping scheme is used to map the 
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CLR ( .Net) types to Java types during Java proxy 
generation. An example of CLR to Java type mapping is 
shown in Table 1. 



Table 1: CLR- to -Java Mapping 



CLR Type 


Java Type 


Description 


void 


void 


Void 


bool / Sys t em . Boo 1 ean 


boolean 


True/false value 


char/ Sys tern . Char 


char 


Unicode 16 hie char 


string/System. String 


j ava . lang. String 


Unicode StTrincr 


f loat3 2 /System, single 


float 


IEEE 3 2 -bit float 


float 64/Sys tern. Double 


double 




int8/System. Intfl 


byte 


Signed 8 -bit integer 


intl6/System. IntlS 


short 


Signed 16-bit integer 


int32 /System. Int32 


int 


Signed 32 -bit integer 


int64/System. Xnt64 


long 


Signed 64 bit integer 


unsigned int8/System.Byte 


byte 


Unsigned 8 -bit integer 


unsigned intl6/System.UIntl6 


short 


Unsigned 16 -bit integer 


unsigned int32/System.UInt32 


int 


Unsigned 32-bit integer 


unsigned int64/System.UTnt64 


long 


Unsigned 64-bit integer 


System. Object 


j ava . lang . Ob j ect 


Base class for all objects 


System. MarshalByRef Ob j ect 


java. lang. Object 


Base class for all objects 
passed by reference 



There is a direct one-to-one mapping of .Net classes 



and Java classes. For example, a .Net class called "C" in 
the namespace "A.B" will generate a Java class named "C" in 

10 a Java package named "A.B". More importantly, the class 
hierarchy is maintained between the .Net and Java classes. 
This means that Java proxies are generated for the super 
classes and implemented interfaces of a .Net class as well. 
However, Java proxies are only generated for those .Net 

15 classes with public access. Arrays of class types are also 

8 
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supported, so that an array of x dimensions in .Net is 
mapped onto an array of x dimensions in Java. 

Marshal by reference classes represent remote objects 
5 that return a proxy instead of passing along the object. 
Each access to the proxy therefore incurs a remote access 
to the original remote object. 

.Net constructors with parameters are also supported. 
10 Each public constructor in a .Net class generates two 
corresponding Java constructors in the Java proxy. For 
example, the .Net constructor: 

public Aclass (String s) { } 

15 

results in the generation of two Java constructors: 
public Aolass (String s) throws RemoteException {} 
20 and 

public Aclass (String s, String URI, String format. Boolean 
clietitActivated) throws RemoteException { } 

25 Both of the Java constructors use the same .Net 

constructor, however the first Java constructor reads the 
configuration parameters for the class from the 
configuration file, whereas the second Java constructor 
allows the configuration file settings to be overridden. 

9 
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By specifying any or all of the configuration details 
listed as parameters in the Java constructor, the settings 
in the configuration file are overridden by the parameter 
value . 

5 

The Java constructors can also throw a RemoteException 
in case of a communication failure, or in the event of an 
exception being thrown in the remote constructor itself. 

10 For each public method in a .Wet class, an equivalent 

3 Java method is generated. As with constructors, each 

" 'is. 

^ method can throw a RemoteException in case of a 

i^- communication failure, or in the event of an exception 

g being thrown in the remote method itself. 

i* 15 

* Marshal by value classes are used when the class is a 

g; container for data, Marshal by value classes are 

serialized and transmitted. The Java proxy for a marshal 
by value class contains the fields of the .Net class as 
20 public variables, and no methods. Access to the fields 
does not incur any extra remote access. 

For a given .Net interface, a Java interface and a 
Java class are generated. For example, for a .Net 
25 interface *lf ace" , a Java interface xx lface" and a Java 

10 
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class w IfaceProxy" are generated. The Java interface is 
used by the Java client code, whereas the Java class is 
used by the runtime to marshal calls through the Java 
interface. Methods in the interface are mapped as 
5 described for the marshal by references classes above. 

.Net to Java development 

Ja.Net also allows the generation of .Net proxies in 
10 order to access a Java Virtual Machine™. The proxy files 
are C# source files (.cs) that implement classes and class 
4i members corresponding to those found in the specified Java 
classes. 

/ 15 The development steps for .Net-to-Java communication 

yk are shown in the flowchart of Figure 2. The first step 20 

is to specify the names of the Java classes for which a 
T*. .Net proxy is required using a GenNet tool. This 

information is provided as metadata (an XML file) . 

20 

The next step 22 is to send the metadata to the .Net 
client. This can be achieved by using GenService as 
discussed above for Java-to- .Net communciation. 

25 When the .Net client receives the metadata XML file, 

GenService is used to generate (step 24) the necessary C# 

11 
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classes to parallel the classes and interfaces listed in 
the metadata. The generated classes have all the methods 
and properties of the Java classes. A mapping scheme is 
used to map the Java types to CLR. (.Net) types during C# 
5 class generation. An example of CLR to Java type mapping 
is shown in Table 2. Finally, the C# files are compiled 
(step 26) into a proxy assembly so that the .Net client can 
access Java while Ja.Net is in runtime mode. 

10 Table 2: ffava-to-CLR. Mapping 



ill 



Java Type 


CLR Type 


Description 


void 


void 


Void 


boolean 


bool 


True/false value 


char 


char 


Unicode 16 bit char 


java. lang, String 


string 


Unicode String 


float 


float32 


IEEE 32-bit float 


double 


float64 


IEEE 64-bit float 


byte 


intS 


Signed 8-bit integer 


short 


int!6 


Signed 16-bit integer 


int 


int32 


Signed 32 -bit integer 


long 


int 6 4 


Signed 64 bit integer 


Java. lang. Boolean 


bool 


True /false value 


Java. lang. Char 


char 


Unicode 16 bit char 


Java. lang. Float 


float32 


IESE 3 2 -bit float 


Java , 1 ang . Doub 1 e 


float64 


IEEE 64 -bit float 


Java. lang. Byte 


intS 


Signed 8 -bit integer 


Java . lang , Short 


intl6 


Signed 16 -bit integer 


Java. lang. Integer 


int32 


Signed 32 -bit integer 


Java . lang . Long 


int 6 4 


Signed 64 bit integer 


java. lang. Object 


System. MarshalByfcef Ob j act 


Base class for all objects 
passed by reference 



There is a direct one-to-one mapping of .Net classes 



and Java classes. Arrays of class types are also 
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supported, so that an array of x dimensions in Java is 
mapped onto an array of x dimensions in .Net. 

Marshaled classes, constructors and interfaces are all 
5 mapped in a similar fashion as described above for Java-to- 
.Net communication. 

Runtime mode 

In order to use the proxies generated in the 
10 development mode in a user application, a Ja.Net runtime 
pi tool is required. The Ja.Net runtime tool provides bi- 

# directional communication between Java and .Net using the 
proxies generated in the development mode. 

15 Figure 3 shows communication between a Java client 30 

* and a .Net component 36 using the Ja.Net runtime 34. The 
Java client 30 accesses the Ja.Net runtime 34 via the Java 
proxies 32 generated by GenJava. The Ja.Net runtime 34 
then converts calls to Java proxies to .Net Remoting calls 

20 in order to access the -Net component 36. 

Figure 4 shows communication between a .Net client 40 
and a Java component 46 using the Ja.Net runtime 44. The 
.Net client 40 invokes the .Net proxies 42 generated by 
25 GenNet. The Ja.Net runtime 44 converts .Net Remoting calls 

13 
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from the .Net proxies 42 in order to access the Java 
component 46. 

The Ja.Net development tool is preferably distributed 
5 with the Ja.Net runtime tool, to allow for optimization and 
verification of applications in development. However, the 
Ja.Net runtime tool may be distributed by itself to allow 
end users to run applications developed for Ja.Net. 

10 Accordingly, while this invention has been described 

with reference to illustrative embodiments, this 
description is not intended to be construed in a limiting 
sense. Various modifications of the illustrative 
embodiments, as well as other embodiments of the invention, 

15 will be apparent to persons skilled in the art upon 
reference to this description. It is therefore 
contemplated that the appended claims will cover any such 
modifications or embodiments as fall within the scope of 
the invention. 
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